Closes #1473.

Summary

This PR adds traffic rule version history, diff, and rollback support for governor-managed traffic rules in Dubbo Admin.

Covered rule kinds:

• Condition Route
• Tag Route
• Dynamic Config / Configurator

Live traffic rules remain owned by the existing ResourceManager, registry, and dynamic configuration write paths. RuleVersion is an audit/history ledger and rollback source; it is not the live source of truth.

Versioning for supported governance rule mutations is fail-closed. Create, update, delete, and rollback must record the version ledger entry before the registry mutation is allowed to proceed. maxVersionsPerRule=0 disables retention trimming only; it does not disable version recording.

What changed

Backend

• Adds RuleVersion as a first-class resource for recording traffic rule history entries.
• Adds backend APIs for listing history, reading version details, comparing versions, comparing a version against current live state, and rolling back to a previous CREATE/UPDATE version.
• Records version ledger entries for create, update, delete, and rollback before the corresponding ResourceManager write.
• Restores the original per-rule distributed lock around the full mutation critical section:
  • load current live rule / ensure baseline
  • append RuleVersion
  • apply retention if needed
  • perform ResourceManager add/update/delete/upsert
  • return the service result
• Captures a BOOTSTRAP baseline entry before the first admin-side modification of an existing rule with no recorded history.
• Keeps ByParentRule indexing so history can be queried by the parent traffic rule.
• Uses the project’s existing Console API response contract for rule-version handlers: HTTP 200 with CommonResp.code/message/data.

Frontend

• Adds history entry points to the traffic rule pages.
• Adds a history drawer, version detail view, diff editor, rollback dialog, rollback reason input, and refresh-after-rollback flow.
• Keeps stale-response guards for request/selection changes.
• Uses i18n for rule-history labels instead of hard-coded English in traffic views.
• Does not disable rollback merely because a history entry is isLatestRecorded. The backend remains authoritative for detecting already-current / same-content rollback attempts. The UI only disables DELETE markers.

Design decisions

Versioning is fail-closed

Supported governance rule mutations do not fall back to the old raw registry write path when rule versioning is unavailable. If the versioning service, store, or append path is unavailable, the mutation returns an error and does not write the registry.

The write path is ledger-first inside the same per-rule distributed lock: record the corresponding RuleVersion entry, then perform the normal ResourceManager mutation. If ledger recording fails, registry mutation is blocked. If the later registry write fails, the API returns that error and does not report success.

Rollback authority

Rollback to a DELETE marker is rejected.

Rollback to a version whose content hash already matches the current live rule is rejected by the backend. The frontend intentionally does not try to precompute this with an extra current-hash request, because that would enlarge the API surface and still race with concurrent writes.

Diff ownership

The core versioning service owns history-to-history diff semantics:

• explicit version ID vs explicit version ID
• version vs previous recorded version

The console service owns against=current, because current means the live ResourceManager / registry state, not the latest recorded ledger entry.

Previous-version lookup explicitly sorts versions by VersionNo descending before selecting the previous version; callers do not depend on store return order.

DELETE versions

DELETE versions are absence markers represented by the canonical empty spec JSON marker. They are kept for audit/history continuity and to show that a rule was removed.

DELETE markers are not rollback targets. To restore deleted content, users must roll back to an earlier CREATE or UPDATE version.

BOOTSTRAP baseline

BOOTSTRAP means a baseline/import entry for an existing rule when it is first brought under version tracking. It is not limited to startup and is not registry reconciliation.

Compatibility fixes included

This PR keeps the traffic form field preservation fix because rollback and rule-history smoke paths depend on rule form round-tripping without losing fields.

The compatibility fix is intentionally scoped to preserving existing traffic rule fields such as priority, force, configVersion, and dynamic config rows while editing forms. It is not part of the core versioning model.

CI-only fixes included

The workflow cache update for the Vue build is retained as a validation-only fix so PR checks can install frontend dependencies consistently.

This has no runtime behavior change.

Removed / out of scope

Store-level CAS/OCC is not part of this PR. The previously experimental UpdateIfUnchanged and transient store error code were removed because they were not exposed through ResourceStore and were not connected to the traffic rule write path.

This PR does not add external registry reconciliation, durable intent repair APIs, or a separate conflict-resolution UI.

Tests

Backend tests cover:

• create/update/delete normal paths writing the version ledger
• condition/tag/dynamic create/update/delete taking the corresponding per-rule distributed lock
• history append and registry mutation occurring inside the same lock critical section
• rollback taking the same per-rule lock and writing history plus registry inside the lock
• fail-closed behavior when versioning is unavailable
• fail-closed behavior when ledger append fails before registry mutation
• registry write failure returning an error instead of pseudo-success
• baseline/import entry before first mutation of an existing rule
• DELETE marker storage as an absence marker
• DELETE marker rollback rejection
• rollback recording a new source=ROLLBACK version
• rollback ledger append failure blocking registry mutation
• current diff reading live ResourceManager state
• previous diff sorting unordered store results by VersionNo
• explicit version ID diff
• zero retention config still recording versions
• rule-version handler errors using HTTP 200 + CommonResp

Frontend tests cover:

• latest recorded non-DELETE history entries keeping rollback available
• DELETE marker rollback being disabled
• backend same-content rollback rejection being shown to the user
• history list/detail stale-response guards
• rollback dialog stale-response guard
• dynamic config form configVersion and config row round-trip
• condition route form edit round-trip preserving priority, force, and configVersion

Validated locally:

git diff --check apache/develop
make test
go test ./pkg/core/versioning ./pkg/console/service ./pkg/store/memory ./pkg/store/dbcommon ./pkg/core/store/...
go vet ./pkg/core/versioning ./pkg/console/service ./pkg/store/memory ./pkg/store/dbcommon ./pkg/core/store/...

cd ui-vue3
npm run test -- RuleHistoryPanel.spec.ts
npm run test -- ConfigModel.spec.ts updateByFormView.spec.ts
npm run type-check

npm run type-check still fails on existing broader project TypeScript issues outside the touched versioning/form files, including the missing declaration file for js-cookie, legacy TAB_STATE unknown typing in untouched add/update/YAML traffic views, and unrelated home/resources page type errors. All PR-touched traffic/versioning files are clear of type-check errors; the remaining failures are outside the PR diff.